home *** CD-ROM | disk | FTP | other *** search
/ Amiga Game-Power / Amiga Game-Power.iso / pd mix ii / access / hddriver / readme < prev   
Encoding:
Text File  |  1994-05-20  |  6.1 KB  |  127 lines
  1. Driver Information
  2. ==================
  3.  
  4. These comments are totally scrambled. Hope it makes some sense.
  5. Oh well, what do you expect for free?
  6.  
  7. This driver was written for a WD-1002-05 hard disk controller card.
  8. This card can handle 3 hard disks and 4 floppies, but my driver can
  9. handle only one hard disk.
  10. The driver was written for Aztec C 3.4a. I dont know how hard it would be
  11. to port to Lattice.
  12.  
  13. The article in this directory was printed in the Workbench newsletter
  14. published by AUG (the Amiga User Group inc. in Melbourne Australia).
  15. It may contain a few inaccuracies as it was written a long time before
  16. this version of the driver. In particular it does not handle autoloading.
  17. It does however give an introduction to the EXEC and message passing.
  18.  
  19. To use the driver, "harddisk.device" must be copied into your devs:
  20. directory and the MountList file modified for your hard disk. I
  21. use 4 partitions but I am not sure why. Stops the C: directory being
  22. scattered all over the disk I guess. Also I can back up one partition
  23. in another if I want to.
  24.  
  25. The directory "driver" contains the actual hard disk device driver.
  26. The "support" directory contains support routines (such as to format
  27. the hard disk and to later analyse it). The "driver" directory must
  28. be compiled before the "support" directory.
  29.  
  30. The support directory contains a general purpose initiate/read/write
  31. program for the hard disk. You must run initiate with the f option
  32.     usage: initiate logfile commands [inputfile]
  33. The logfile just keeps track of what is going on (I usually used PRT:).
  34. Commands is a string of characters. Legal characters are 'f' 'r' 'w'.
  35. The 'f' option requires the optional input file which specifies
  36. which sectors are bad (the WD-1002-05 controller card does not do
  37. automatic bad sector removal). I probably should have mapped out
  38. bad tracks to reduce the size of the map table, but with sectors
  39. it should be possible to write a utility to unlink a bad sector from
  40. an already formatted hard disk. The 'r' and 'w' options read or
  41. write to the whole disk. If any bad sectors are detected in any of
  42. the commands, the sector is relinked (via a table in the first sectors
  43. of the disk - see struct hd_FirstSector in harddisk.h). Sectors
  44. are removed from the beginning of the disk, so in your MountList
  45. file, YOU MUST NOT USE SECTORS NEAR THE BEGINNING OF THE DISK!!!
  46. I left 10 cylinders for future errors.
  47. To format my disk I used
  48.     initiate PRT: frwr disk_info
  49. This formatted the disk (using the details in disk_info) then read
  50. the whole disk, wrote the whole disk, and re-read the whole disk.
  51. THIS TAKES A VERY LONG TIME AND CANNOT BE ABORTED OR ELSE THE BAD
  52. SECTOR MAP WILL NOT BE UPDATED ON THE DISK. You may wish to do
  53. several commands one after the other.
  54.  
  55. The "readdisk" program just reads the whole disk reporting errors.
  56. It never modifies the disk.
  57.  
  58. The "interleave" program tries different interleave factors and times
  59. the access speeds. This should be done before formatting the disk.
  60. If it says an interleave factor of say 5, I would advise using a larger
  61. one as there are extra delays inserted by AmigaDOS. Perhaps you should
  62. first format a very small partition and try out some different interleave
  63. factors with AmigaDOS.
  64.  
  65. This version of the code is all interrupt driven. It assumes that
  66. interrupt level 2 is used. I used to have it so it would busy wait
  67. with a Delay(1L) call in the loop so it would not hog the CPU.
  68. This works, but is obviously not as good.
  69.  
  70. I could not stop the linker wanting _main() so I ended up writing
  71. my own dummy main. This is strange as I have defined my own .begin.
  72. Perhaps I am using some globals from the library or something?
  73.  
  74. The support routines have not been tested for a while as they could
  75. change my hard disk and I have got all my software on it! I think
  76. they should work ... they link and did work at one stage (when I was
  77. formatting my disk).
  78.  
  79.  
  80. CACHING
  81. =======
  82.  
  83. I have tried three caching algorithms. The different schemes had a very
  84. small effect on the end speed of the system. AmigaDOS is just putting
  85. such a huge overhead on everything.
  86.  
  87. The first scheme does no caching at all. One big problem I found was
  88. that if you ran two programs at once, it read one sector from the
  89. first file, then one sector from the second, then one from the first
  90. and so on. This resulted in the disk seeking up and down for ages.
  91. (this also happens with floppies). To overcome this, I had a look
  92. inside the sector structure. AmigaDOS links all its sectors together
  93. in a chain. To stop thrashing, I implemented a caching scheme
  94. which attempted to identify sequential reads from a file and
  95. when detected, the driver would read a number of pages for the
  96. file (by following the next pointer links in the sectors).
  97. This meant that it would read large chunks of one of the files
  98. before going to the second. Later calls for the first file
  99. did not require a seek. I also buffered all write commands
  100. and sorted them. If the disk ever seeked past a track with
  101. a buffered write, it did the write on the way past.
  102.  
  103. This caching was non-trivial but worked quite well. It however did
  104. not help with directories. As a result of looking at how AmigaDOS
  105. places sectors on the disk, I rewrote the caching algorithm to buffer
  106. the last 10 tracks accessed. This worked much better. When multiple
  107. programs were run together track buffers would load 17 sectors for
  108. each track (AmigaDOS allocates sectors for files by track) which
  109. would hopefully be useful later on. This type of buffering also
  110. helps a lot with directory entries. I tried to improve the driver
  111. by buffering directory entries more than normal sector entries.
  112. This is because I considered it more likely to do multiple directory
  113. commands than to re-load the same file multiple times.
  114. If you are going to run a command a lot, you should probably put
  115. it in your ram disk anyway. This time, I did not bother caching
  116. disk write commands so the disk can still thrash if two programs
  117. write to the disk at the same time.
  118.  
  119.  
  120. Well, I hope this has been of some help.
  121. Please let me know if you find any errors.
  122. The code is all copyright. I grant full permission for individuals
  123. to use it for what ever they want, but if someone wants to use
  124. it and make money from it, they will have to contact me first.
  125.  
  126. Alan Kent
  127.